Visit the preview URL for this PR (updated for commit 75d1266):

https://yew-rs-api--pr4088-perf-domslot-path-co-hkn87gb5.web.app

_{(expires Sat, 25 Apr 2026 03:15:56 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

Benchmark - core

Yew Master

vnode           fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ vnode_clone  2.458 ns      │ 2.489 ns      │ 2.461 ns      │ 2.464 ns      │ 100     │ 1000000000

Pull Request

vnode           fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ vnode_clone  2.458 ns      │ 3.182 ns      │ 2.466 ns      │ 2.491 ns      │ 100     │ 1000000000

Size Comparison

✅ None of the examples has changed their size significantly.

Benchmark - SSR

Yew Master

Pull Request

benchmarks looking good 0454fc7#commitcomment-180899917

To clarify, it helps with the performance but doesn't actually address the original comment.

The 𝒪(𝑁²) comes from the chain structure itself: child[0] chains through 𝑁-1 hops, child[1] through 𝑁-2, etc. To eliminate this, BList would need to resolve insertion positions without chaining, for example by maintaining a side structure that maps each child index to its resolved DOM node reference, updated eagerly when positions change. That will be a larger refactor of how BList and NodeWriter interact with DomSlot.

I explored a possibility in #4090 briefly but couldn't make it work correctly

What you would need is a (self-balancing) tree structure, such as an AVL or Splay (not sure what the best here is - depends on usage I suppose). You need to be able to split and merge the tree (when you reassign a node in the middle) and find the right-most node starting from any node in the middle. Worst case could be O(log n) and most likely even close to O(1) if you splay correctly. I never did get it to work either though when I tried. Something about the intrusive nature of parent pointers in trees and the balancing operations needed and I didn't find an existing impl that fit to not have to invent it here.

EDIT: "worst case" should probably be "amortized" in the above, a true online worst case structure would be more complicated, see e.g. Scapegoat tree or Multi-Splay tree. It really does get hairy!

Actually, the current structure might not actually form a simple chain, but a tree. You can tell multiple DynamicDomSlots to track the same DomSlot, which can be another DynamicDomSlot etc forming a tree (although in code you go from child to parent). I'm not sure if this capability is used, or if it's simply accidental because it's not so easy to break the assignment of any other DynamicDomSlot that might be assigned to it. In this general form one would need to form a link/cut tree, which I don't fully understand.